[CLOSED] Support Quick Docs (Web Platform Docs) in HTML #8910
Comments
|
|
|
We're using this in Bramble, and we noticed that there's no support for "html/elements/i": {
"SUMMARY": "<p>The <strong>i</strong> element indicates that the contained text is in an alternate voice, mood, or language from the surrounding text. ",
"URL": "https://docs.webplatform.org/wiki/html/elements/i"
},
"html/elements/iframe": {
"SUMMARY": "<p>The <strong>iframe</strong> element (<iframe>) introduces a new nested browsing context. ",
"URL": "https://docs.webplatform.org/wiki/html/elements/iframe"
},The docs are at https://docs.webplatform.org/wiki/html/elements/img. If what I'm seeing in |
|
Oh that's weird. The Web Platform API returns an empty summary for this and only this page ( |
|
|
|
|
|
|
|
I'm not fully aware of wha's in use on WebPlatform systems by Brackets. Are you now using rendered HTML and the API or only one of them? I'm asking because a major overhaul is in the works and I might remove completely MediaWiki from the equation. It'll instead use contents from a git repo written in Markdown (see https://github.com/webplatform/docs repo), and converted into static pages (see https://github.com/webatform/generator-docs repo). I'm doing my best to carry over metadata but I am limited in the time I can spend working on this project. A lot had to be done and I am about to have no time left to work on it. Problem is that I can't work much longer on the conversion as my position at the W3C ended and we decided to focus on keeping content and history to a simpler system. API wasn't a priority. If I could find a format that could still work for Brackets, maybe I could fold a Metalsmith generator pass and have a static-file based response body digestible by Brackets. |
|
From that side, it's supposedly not an issue to switch our generator script over to GitHub-hosted Markdown files (I guess Metalsmith is capable of extracting the summary out of Markdown, isn't it?) |
|
Oh, thanks for the reminder As for where you get the data, you do like I did; use MediaWiki API Parser to give a JSON string that contains the HTML it would render. I wish I discovered that earlier. That's what I based my work on https://github.com/webplatform/mediawiki-conversion too. This makes me wonder now how I could help you get the data instead. If you look at how i'm converting content into Markdown you'll see that I could extract some stuff up into front matter. Each page becomes a folder with a file With that being said, I thought to create a What do you think? PS: Original idea of moving to front matter was to enable us to eventually make an ElasticSearch index and structure data for use during HTML generation pass. ---
title: border-radius
attributions:
- 'Mozilla Developer Network [](http://creativecommons.org/licenses/by-sa/3.0/us/): [[Border-radius](https://developer.mozilla.org/en-US/docs/CSS/border-radius) Article]'
- 'Microsoft Developer Network: [[Windows Internet Explorer API reference](http://msdn.microsoft.com/en-us/library/ie/hh828809%28v=vs.85%29.aspx) Article]'
code_samples:
- 'http://gist.github.com/5495188'
overview_table:
'[Initial value](/css/concepts/initial_value)': '`0`'
'Applies to': 'All elements, except the table element when border-collapse is collapse'
'[Inherited](/css/concepts/inherited)': 'No'
Media: visual
'[Computed value](/css/concepts/computed_value)': 'As specified by individual properties'
Animatable: 'Yes'
'[CSS Object Model Property](/css/concepts/cssom)': '`borderRadius`'
Percentages: 'Refer to the corresponding dimension (width or height) of the border box.'
readiness: 'Ready to Use'
standardization_status: 'W3C Candidate Recommendation'
summary: 'The border-radius CSS property allows authors to round the corners of an element. The rounding can be different per-corner, and it could have different horizontal and vertical radii, to produce elliptical curves.'
tags:
- CSS
- Properties
todo_broken_links:
note: 'During import MediaWiki could not find the following links, please fix and adjust this list.'
links:
- dom/defaultSelected
uri: css/properties/border-radius |
|
Making clever use of the GH API and some other clever tricks, I guess I can make it work with the new Markdown content as well. |
|
Maybe I should use the Could you help me there and do similar work for other parts of the site? If you could create sets of JSON or YAML files for each folder that has metadata to extract from SMW, that would be much helpful! |
|
So, I don't really know what exactly you want me to do, even though I'd like to help. |
|
Hi, |
|
I'm also honestly thinking about switching over to MDN docs, as they are more recent, more thorough, and more commonly used. What do you think, |
|
|
|
Inviato da smartphone Sony Xperia™ ---- Marcel Gerber ha scritto ----
|
|
|
|
fwiw, we wrote an MDN based version of this a long time ago as a separate extension: https://github.com/mozilla/brackets/tree/master/src/extensions/extra/MDNDocs |
|
On a related note; On Feb 17, 2017 11:24, "David Humphrey" [email protected] wrote:
|
|
[[ Hit send too quickly ]] On a related note.
Also, for compatibility data at Mozilla, you should have a look at https://browsercompat.herokuapp.com It's a nice project to expose compat data and specs status over JSONAPI On Feb 17, 2017 11:24, "David Humphrey" [email protected] wrote: fwiw, we wrote an MDN based version of this a long time ago as a separate — |
|
Some questions, things I noticed:
|
|
|
|
cc |
|
On a related note. W3C system Team actually did flip the switch off from WebPlatform Docs' All of it is now only static HTML hosted on GitHub pages reading from This is to nail the point that WebPlatform is on its own. W3C and all Unless a comunity emerges. That's outside of the scope of this ticket. We should close this issue. RenoirRenoir Boulanger |
|
|
|
Yeah, will do that |
|
These changes were merged as part of adobe/brackets#13268 and adobe/brackets#13285. |
Thursday Nov 27, 2014 at 18:28 GMT
Originally opened as adobe/brackets#10036
Enables Quick Docs for HTML.
Data is still from Web Platform Docs, while HTML data is in
html.jsonand CSS data incss.json.As there's docs for both tags and attributes, the behaviour is different based on the cursor position.
Also, there's a new
fullscreen-summaryclass applied when there's only a summary to display and nothing else (this can happen for CSS as well, but only for very few properties). But HTML docs only consist of a summary and thus, it would look odd if it was only half-screen.Also, the summaries are mostly only consisting of one or two lines (that's what a summary is for) and in fact, that's really short. So I guess the main benefit of Quick Docs in HTML is having the "Read more" link for most users (to get things like Examples, syntax, ... that we can't access via their API). But for some users, like for those learning HTML, even such a short summary can be really helpful.
For #9566.
MarcelGerber included the following code: https://github.com/adobe/brackets/pull/10036/commits
The text was updated successfully, but these errors were encountered: