Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Should we remove <style>'s language-agnostic spec prose? #2995

Closed
domenic opened this issue Sep 3, 2017 · 2 comments
Closed

Should we remove <style>'s language-agnostic spec prose? #2995

domenic opened this issue Sep 3, 2017 · 2 comments
Assignees
@domenic
Labels
clarification Standard could be clearer topic: style

Comments

@domenic
Copy link
Member

domenic commented Sep 3, 2017

Right now the spec tries to be agnostic and allow user agents to support other styling languages.

We could collapse this level of indirection and just make <style> a way of injecting CSS.

We could go further:

  • Do the same for <link rel="stylesheet">
  • Make specifying type="text/css" discouraged by conformance checkers

Opinions? @zcorpan especially, maybe @tabatkins as well.
@domenic domenic added the clarification Standard could be clearer label Sep 3, 2017
@domenic domenic mentioned this issue Sep 3, 2017
Closed
@annevk
Copy link
Member

annevk commented Sep 3, 2017

I think that makes sense given that nobody uses it for anything else and just like script has event handlers that are tightly coupled with JavaScript, style has style="". If we ever did get another language for stylesheets we'd probably figure out exactly what kind of model changes we'd need at that point.

@tabatkins
Copy link
Collaborator

Yup, I agree with @annevk. Just make it CSS-specific for now; if we ever grow a second styling language, then we'll know what we need to do to accommodate it, and can make the necessary changes. Until that day, we've only got one language and no plans to add additional ones, no reason to be unnecessarily generic.

@domenic domenic self-assigned this Sep 7, 2017
domenic added a commit that referenced this issue Sep 8, 2017
@domenic
Improve <style> and <script> processing and conformance
509e84f 
* De-genericizes <style> and <link rel="stylesheet"> to only deal with
  CSS. Fixes #2995.
* Makes type="" on <style> "obsolete but conforming", since it is always
  redundant.
* Makes type="(a JS MIME type)" on <script> obsolete but conforming as
  well. Previously we had a "should" requirement but had not recorded it
  in the centralized obsolete-but-conforming section that collects such
  requirements.
* Makes <style> operate on child text content. Fixes #2996.
* Adds pointers to #2997.
* Makes it clearer that parameters are not allowed in the content type
  value for script or style. Fixes #3022.
domenic added a commit that referenced this issue Sep 8, 2017
@domenic
Improve <style> and <script> processing and conformance
34d65dd 
* De-genericizes <style> and <link rel="stylesheet"> to only deal with
  CSS. Fixes #2995.
* Makes type="" on <style> "obsolete but conforming", since it is always
  redundant.
* Makes type="(a JS MIME type)" on <script> obsolete but conforming as
  well. Previously we had a "should" requirement but had not recorded it
  in the centralized obsolete-but-conforming section that collects such
  requirements.
* Makes <style> operate on child text content. Fixes #2996.
* Replaces the conformance requirement (noted in the source as
  "temporary") prohibiting unmatched comment-like syntax inside <style>
  with a conformance requirement to be valid CSS.
* Adds pointers to #2997.
* Makes it clearer that parameters are not allowed in the content type
  value for script or style. Fixes #3022.
@domenic domenic mentioned this issue Sep 8, 2017
Merged
annevk pushed a commit that referenced this issue Sep 14, 2017
@domenic @annevk
Improve <style> and <script> processing and conformance
9c612ac 
* De-genericizes <style> and <link rel="stylesheet"> to only deal with
  CSS. Fixes #2995.
* Makes type="" on <style> "obsolete but conforming", since it is always
  redundant.
* Makes type="(a JS MIME type)" on <script> obsolete but conforming as
  well. Previously we had a "should" requirement but had not recorded it
  in the centralized obsolete-but-conforming section that collects such
  requirements.
* Makes <style> operate on child text content. Fixes #2996.
* Replaces the conformance requirement (noted in the source as
  "temporary") prohibiting unmatched comment-like syntax inside <style>
  with a conformance requirement to be valid CSS.
* Adds pointers to #2997.
* Makes it clearer that parameters are not allowed in the content type
  value for script or style. Fixes #3022.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
@domenic
Improve <style> and <script> processing and conformance
771c5b0 
* De-genericizes <style> and <link rel="stylesheet"> to only deal with
  CSS. Fixes whatwg#2995.
* Makes type="" on <style> "obsolete but conforming", since it is always
  redundant.
* Makes type="(a JS MIME type)" on <script> obsolete but conforming as
  well. Previously we had a "should" requirement but had not recorded it
  in the centralized obsolete-but-conforming section that collects such
  requirements.
* Makes <style> operate on child text content. Fixes whatwg#2996.
* Replaces the conformance requirement (noted in the source as
  "temporary") prohibiting unmatched comment-like syntax inside <style>
  with a conformance requirement to be valid CSS.
* Adds pointers to whatwg#2997.
* Makes it clearer that parameters are not allowed in the content type
  value for script or style. Fixes whatwg#3022.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@domenic domenic

Labels
clarification Standard could be clearer topic: style
Milestone
No milestone
Development

No branches or pull requests
3 participants
@domenic @tabatkins @annevk