New CSSOM view API landing page, move CSS guides under #40547
Conversation
Josh-Cena
requested review from
estelle,
pepelsbey and
sideshowbarker
and removed request for
a team
github-actions
bot
added
Content:CSS
|
We should probably move this to a discussion. I just recently (last week) added https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_custom_highlight_API to the docs. We also have a https://developer.mozilla.org/en-US/docs/Web/API/CSS_custom_highlight_API page. They serve different purposes. Similarly, https://developer.mozilla.org/en-US/docs/Web/CSS/CSSOM_view could have a https://developer.mozilla.org/en-US/docs/Web/API/CSSOM_view page (we have https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model, so we do have it). The page should not be moved / removed from the CSS module landing pages section because CSSOM is a CSS module. Every CSS spec should have a CSS module landing page. I've been working on that for .... checks calendar .... almost 2 years? |
|
If a CSS spec does not define any at-rules, selectors, properties, functions, or types, then it would have nothing to be associated with in the CSS docs. In the future when we have features nested under the module folders, these modules would weirdly have nothing under them because well they are not CSS. CSS highlight API does have both CSS and API, so it should rightfully be documented under both, but CSSOM view is purely a web API that just happens to be standardized by CSSWG. For example, the websec group also publishes API bindings such as the reporting API, and that is documented as a web API as opposed to an HTTP feature. Thinking about it from another perspective: anything called "X object model" inherently is a web API, not "X" itself. For example DOM is not nested under XML or HTML, and neither is SVG DOM or HTML DOM. They are all inherently bindings in the API realm that enable working with the said language. Similarly anything branded as "CSSOM" is not "CSS", but a foreign interface for interacting with CSS. |
|
This pull request has merge conflicts that must be resolved before it can be merged. |
Josh-Cena
force-pushed
the
cssom-view-api
branch
from
30bdd2f to
4318fd6
Compare
|
This pull request has merge conflicts that must be resolved before it can be merged. |
|
Update as said in the last editorial: I think we should keep the module page (as it is a CSS module page type) but review the documentation of this under the API section and make sure it is complete there as well 👍 |
|
Porting over my question from Discord: What's the definition of a "CSS module"? Why can something that defines no CSS language feature be considered a CSS module? |
|
This pull request has merge conflicts that must be resolved before it can be merged. |
|
We should include a module landing page in the CSS module landing page section for all CSSWG specifications. The CSS module pages include the IDLs introduced in the spec, so omitting the a spec because it doesn't include properties would mean those are the only CSS spec IDLs not included in the CSS module section. All the CSSWG specs are modules, but modules are not limited to the CSSWG . Specs from https://drafts.fxtf.org like masking, filtering, motion, etc., are also modules. |
Josh-Cena
force-pushed
the
cssom-view-api
branch
from
92ce4a9 to
b211c84
Compare
Josh-Cena
force-pushed
the
cssom-view-api
branch
from
de1d9ce to
1f22a18
Compare
github-actions
bot
added
size/m
Josh-Cena
force-pushed
the
cssom-view-api
branch
from
1f22a18 to
49a407f
Compare
|
Fair enough. I have no intention to argue with that decision. I've restored the "CSSOM view" module landing page. However, I would like the guides to live under API, because they talk about the semantics of the JavaScript properties and not any CSS feature. |
github-actions
bot
added
size/l
Josh-Cena
changed the title
Josh-Cena
changed the title
Josh-Cena
force-pushed
the
cssom-view-api
branch
from
49a407f to
fdb86e0
Compare
Josh-Cena
force-pushed
the
cssom-view-api
branch
from
fdb86e0 to
01c5ef1
Compare
estelle
left a comment
estelle
left a comment
There was a problem hiding this comment.
The viewport concepts is about JS, HTML, SVG, and CSS, and is very relevant to several CSS concepts, including viewport related values, the CSS viewport module, and the CSS environment variables module. The viewport concepts guide needs to remain in the CSS section.
The coordinate system is related to SVG, JS, and CSS (think all the properties that accept a shape as a value. The example on the coordinate system page is more JS than CSS, so can be moved to the CSSOM View API section under APIs.,
files/en-us/_redirects.txt
Outdated
| /en-US/docs/Web/CSS/CSSOM_view/Coordinate_systems /en-US/docs/Web/API/CSSOM_view_API/Coordinate_systems | ||
| /en-US/docs/Web/CSS/CSSOM_view/Viewport_concepts /en-US/docs/Web/API/CSSOM_view_API/Viewport_concepts |
There was a problem hiding this comment.
OK to move Coordinate_systems but not Viewport_concepts
github-actions
bot
added
size/m
* upstream/main: (32 commits) FF143 GPU import external texture experimental relnote (mdn#41126) added ff release note for nested pseudo-elements (mdn#41146) Add a page for SSRF attacks (mdn#41105) New CSSOM view API landing page, move CSS guides under (mdn#40547) 40778 color input value (mdn#41086) Synchronize with BCD v7.1.5 (mdn#41116) Cross-reference `:target` and `::target-text` pages (mdn#41121) Fix content issues (mdn#41125) Make all JSON code syntactically valid (mdn#41120) Fix the link name with actual heading (mdn#41117) Associated listed form controls (mdn#41096) Mention `new Set()` accepts `undefined` (mdn#41106) chore: correct the `timeRange` function name (mdn#41107) Mention that custom elements constructors can't be directly called (mdn#41069) chore(deps): bump @mdn/fred from 1.3.2 to 1.4.0 (mdn#41111) Public-key cryptography glossary page: add headings and links (mdn#41092) Improve caret color demo contrast (mdn#41104) Fix supported algorithms for HKDF and PBKDF2 (mdn#41100) Update MongoDB example to async/await (driver v5+) (mdn#41102) Remove onload and DOMContentLoaded handlers (mdn#41079) ...
3 participants
I've been long bothered by the fact that "CSSOM view" is not a real API group on MDN. It makes our IA extremely awkward because existing references either have get the sidebar of its owner interface (such as "DOM" for
WindowandDocumentextensions, or "UI events" forMouseEventextensions) or be fakely labeled as "CSSOM". "Visual Viewport API" is also not a real spec anymore. So we basically hacked around the whole issue of lacking a proper API group.Meanwhile we do have a "CSSOM view" landing page, but it's confusingly categorized as CSS, which means it cannot be used as the landing page of a web API group, because of the way our groupdata.json works. All the other CSS specs that define JS bindings, such as CSSOM, CSS Typed OM, etc. are under web API, so I think this should be no exception: the CSS docs should be left to the CSS language proper, not for JS bindings.
I'm adding the groupdata for the new interfaces only. There are too many interface extensions and I'm not interested in updating their sidebars in this PR, although a future one might.