- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 19 Sep 2013 01:24:05 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Style Attributes
----------------
- RESOLVED: Take Style Attribute to PR, with explanation of xml:base
interaction test failure as an xml:base bug.
Spec Preprocessor
-----------------
Tab presented his new spec preprocessor, Bikeshed.
CSSOM
-----
- RESOLVED: setProperty's handling of importance logically behaves same
as appending a declaration (like IE/WebKit)
- RESOLVED: add a setPropertyValue and setPropertyPriority APIs
====== Full minutes below ======
Style Attributes
----------------
fantasai: We have one test failure.
fantasai: Interaction with XML namespaced attributes.
dbaron: Interaction with xml:base and the ordering of attributes.
fantasai: My recommendation is that we just take the impl report and
explain it's not a failure of style attributes, it's a
failure of xml:base.
<fantasai> http://test.csswg.org/suites/css-style-attr/nightly-unstable/report/results.html
fantasai: There's one impl that passes, so it's theoretically possible.
dbaron: It's the interaction of relative urls in style='' and xml:base.
The test has xml:base both before and after the style='', and
it works in some orderings and not others.
dbaron: Turns out nobody actually cares about xml:base.
dbaron: I think we should just argue that this isn't our problem, and
go to Rec with it.
<sgalineau> it's a valid test, but if we can REC with it failing and
it doesn't interop why does it have to be in the test suite?
<zcorpan> {} in style="" in quirks mode:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2517
dbaron: Is this quirk only in Firefox, or in everyone?
dbaron: It used to be present in everyone.
zcorpan: Blink/WebKit and IE now pass (don't have the quirk).
tantek: Sounds like a Moz bug report, not a spec issue then.
fantasai: So are the chairs okay with taking this to rec with the failure?
sgalineau: Why have the test at all if we don't care?
tantek: Historically, we've said that CSS "works" with XML.
tantek: I agree with presenting it as a failure that we don't care about.
tantek: Better to be upfront and point it out.
chrisL: does this work in HTML? We can argue with that too..
dbaron: And it works in CSS with one ordering of the two, just not the
other.
krit: Also, SVGWG agreed not to use xml:base anymore.
chrisl: And it works with the ordering that people use in practice
(xml:base first?), so it's really an edge case.
<tantek> apparently all your xml:base are not belong to us
plinss: I kinda question whether this belongs in this testsuite.
TabAtkins: I think it's fine here - we're not unit-testing, we do need
to test interaction with techs we purport to be compatible with.
fantasai: And we have tests for HTML <base>, so it's appropriate both ways.
glazou: So consensus to move to PR?
RESOLVED: Take Style Attribute to PR.
glazou: Who's doing the transition call?
glazou: Bert.
Scribe: fantasai
Preprocessor / Tools for spec writing
-------------------------------------
ChrisL: One advantage of Tab's preprocessor over Bert's is that it
doesn't require Member access
TabAtkins: Well, I still use the biblio.ref file that's Member-only,
but I have a chached copy on github.
TabAtkins: New processor, wrote mainly so I can use Markdown-style
paragraphs
TabAtkins: Called it Bikeshed, has nice new features
TabAtkins: Like Bert's preprocessor, has automatic linking
TabAtkins: Can use <i> or <a> for cross-linking
TabAtkins: Automatic ID generation, same biblio entry generation
TabAtkins: Tried to copy Bert's functionality as much as possible
<SimonSapin> https://github.com/tabatkins/bikeshed
<SimonSapin> https://github.com/tabatkins/bikeshed/tree/master/docs
<dbaron> https://github.com/tabatkins/bikeshed/tree/master/docs/markup.md
TabAtkins: Additional functionality includes removing all header data,
replace with a <pre> block that gives all the relevant data
TabAtkins: Similarly for propdef tables
TabAtkins: Auto-generates all the boilerplate
<sgalineau> https://github.com/tabatkins/bikeshed
dbaron: Can you tweak the boilerplate if necessary?
TabAtkins: Yes
TabAtkins: Markdown-style paragraphs -- don't need <p> tags, makes text
read more cleanly
TabAtkins: Propdef tables much easier to write
dbaron: Missing 'Animatable' lines
<astearns> http://dev.w3.org/csswg/css-variables/Overview.src.html
for example of boilerplate
TabAtkins: If you're using sublime or ?, have a highlight file
TabAtkins: Bert's preprocessor had two auto-link shortcuts, 'foo' and
''foo''
TabAtkins: I've added a bunch more, e.g. linking to productions
[explains them]
<dbaron> you should say the thing you said about not using tokens in
the docs
TabAtkins: The big feature is cross-spec cross-references
<SimonSapin> \o/
TabAtkins: Even outside of CSS -- any spec that Shepherd processes can
be auto-linked
TabAtkins: Same way as local link
TabAtkins: Really helpful, because it will also catch lots of broken links
TabAtkins: or links to the wrong place
TabAtkins: Bikeshed throws a bunch of errors. Annoying on first convert,
but helps you fix lots of things that were broken
TabAtkins: Common problem that was missed by old processor -- multiple
auto-link targets, used to pick first one, but that was very
often wrong (e.g. linking to ''none'' keyword)
TabAtkins: Help docs
TabAtkins: Another fixup is <pre> block indent stripping
TabAtkins: If you want to indent your sections, but have a pre block,
can't indent the pre contents.
TabAtkins: Bikeshed strips the leading indentation
TabAtkins: So you can indent your <pre> in source, and have it publish
correctly
TabAtkins: Also parses IDL blocks
TabAtkins: Automatically adds definitions to all of them so can auto-link
to them more easily
TabAtkins: Relatively easy to install, just a few dependencies, so can
run it locally.
TabAtkins: Also can use server, just like Bert's -- it's set up on
csswg.org
http://api.csswg.org/bikeshed/
plinss: Also have automatic generation on csswg.org
TabAtkins: If you do a commit with just the src file, will generate the
HTML file on the server
plinss: Nice thing about that is no commits of generated files
<SimonSapin> \o/ again
plinss: It will also regen all the other specs that depend on it
fantasai: It's actually nice to have the generated version in version
control, so that you can link to specific revisions
dbaron: Would prefer if robot committed the regenned versions
Alan: Concerned about case where robot generates a version, but there's
an error, and I never hear about it
TabAtkins: If you want to start using Bikeshed, you do need to know
about auto-linking attributes
TabAtkins: Usually not required but sometimes required
TabAtkins: Auto-link targets are typed,
TabAtkins: CSS types are usually auto-inferred
TabAtkins: But in some cases need to say what type e.g.
attribute DOMString <dfn attribute>name</dfn>;
TabAtkins: Need clarifications when have e.g. term and keyword that
have same text (like 'inherit')
TabAtkins: For more disambiguation, you can declare what a value or
attribute or descriptor belongs to
TabAtkins: by adding a 'for' attribute
TabAtkins: e.g. <a for=flex>none</a>
TabAtkins: Will link to the correct <dfn>none</dfn>, rather than a
random one.
TabAtkins: Only need to do this if it's ambiguous
TabAtkins: Other than that, completely usable. Using it on most specs
that I've touched in last few months
TabAtkins: Several other people are using it, too
krit: [describes fxtf preprocessing toolchain]
<sgalineau> it's preprocessors all the way down
plinss: If there's a spec that bikeshed isn't linking to, trivial to
add to Shepherd
krit: Robin has a spec link database
TabAtkins: [...]
TabAtkins: Pulling from specref repo might be fine
TabAtkins: ... anchors to terms
TabAtkins: If you convert over to bikeshed, we export most things
(like properties, values), but don't export <dfn> terms
by default
TabAtkins: Because specs often define spec-internal terminology
TabAtkins: But can export specific terms by adding export boolean to
<dfn> or <dl> containing <dfn>s.
dbaron: Does it do auto-linking without network access?
plinss: Downloads data from Shepherd
TabAtkins: Doesn't update automatically yet
fantasai: Maybe just set up a cron job to commit an update of the data
every day?
TabAtkins: That would be easy, but won't update people's comps
dbaron: But I could have my daily auto-update script pull the bikeshed
repo
...
TabAtkins: If you have issues inline in your specs, will generate
index of them
TabAtkins: Also, generates links anchoring to section headings etc.
Alan: If you only checkin the source, will auto-generate the processed copy
astearns: Will it also update...
plinss: Anything that server generates, it will regenerate everything
astearns: There's a cross-link between shapes and masking. If I change
one and masking needs to be updated, there should be a
notification for Dirk.
TabAtkins: [...]
plinss: Another nice thing is that, because has extra data about definition
types and what they're for, have been improving Shepherd's spec
processor
TabAtkins: We will be able to have an index of all CSS at-rules, properties,
etc.
TabAtkins: Everybody wants this
TabAtkins: Various efforts to do this, but can auto-gen it now.
plinss: It can be auto-genned on the server, live
Bert: we have a list, but it's auto-generated every 24 hours
TabAtkins: It's just a property list. Can get more info
Bert: But only for specs using bikeshed
plinss: Shepherd is already parsing all he specs all the time
TabAtkins: Most things not with bikeshed, won't have as rich data
TabAtkins: but can still get a lot of it out
plinss: Shepherd is getting better, e.g. now can parse IDL
TabAtkins: If anyone wants help running locally or anything, let me know
TabAtkins: I can also help with converting over your spec
fantasai: Can you make the module template for bikeshed?
Bert: Your documents, they don't use HTML as input
TabAtkins: They use almost HTML
Bert: I like my documents to be valid HTML
TabAtkins: That's fine, just don't use the shorthand syntax
Bert: One criteria for mine was that the input can be valid HTML
TabAtkins: Yes, saw your goals and tried to implement in bikeshed.
TabAtkins: Anything you can do shorthand in Bikeshed, can do longhand
as well
TabAtkins: and has good rerun capabilities (running on its own output)
krit: Markdown?
TabAtkins: Starting a new line of text after a blank line will generate <p>,
unless you flip option to not do that
SimonSapin: it's not actually Markdown, just Mardown-style paragraphs
TabAtkins: yes
* dbaron is glad TabAtkins wrote bikeshed, but hasn't had the chance
to try it yet
CSS Style Declarations
----------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Aug/0431.html
dbaron: Issue is mostly about how CSSOM deals with !important
dbaron: We used to have interop except Presto
dbaron: Except zack changed how Gecko works to match Presto
dbaron: Fundamental issue is what model is for element.style.setProperty
or element.style.foo
dbaron: In a style sheet, if you write
p { color: green !important; color: red; }
dbaron: You get green
dbaron: Even though red is afterward, you wrote !important on the green,
so you get green
dbaron: So if you ask for color in that declaration block, you'd get
the first declaration.
dbaron: My previous mental model for how this works is that, you are
essentially appending another declaration to the block.
dbaron: Suppose you say p.style.color = 'purple'
...?
glazou: the question is "does the absence of the importance means
preserve existing importance?"
dbaron: Multiple questions
dbaron: OM no longer has 'color: red', because only maintains one
declaration for any given property
dbaron: So by the time we have OM, no longer have 'color: red'.
dbaron: So when you do p.setProperty(color, purple)
dbaron: In Webkit/IE/early Gecko
dbaron: This was equivalent to appending a declaration
dbaron: You would not keep purple, because have !important declaration
dbaron: Presto/new-webkit drops the !important declaration and replaces
it with purple declaration
dbaron: There's obscure use cases for ...
* Bert maybe p.style.color.important = purple?
glazou: If importance is not mentioned in setProperty, it sets the
property to the value without importance; doesn't preserve
existing importance.
glazou: CSS editors online and offline are based on that behavior
TabAtkins: dbaron's says that setting prop, effectively appends to block,
get whatever behavior out of that
TabAtkins: Other model is finding exiting declaration and replaces its
value
TabAtkins: Argue for that because API exposed is one for a single
declaration, not a list of declarations
TabAtkins: list-like behavior only shows up in this one particular case
TabAtkins: Don't think we should have this corner case dictate the
underlying model
<sgalineau> fwiw i always thought of style as showing the resolved
cascaded set of declarations; the whole !important business
does feel like it's another API entirely.
dbaron: More things to think about --
dbaron: When you do setProperty(color,purple)
dbaron: Can get green !important, purple, or purple !important
dbaron: Think third option should not be
glazou: I agree with dbaron
dbaron: Don't think we should change the existing API to distinguish
between omitted argument and empty string, particularly because
original API required all three arguments.
?: Are there browsers that require third arguments?
dbaron: Gecko did for awhile, so there is a big pile of existing content
that uses the third argument because it was required.
glazou: I think we're having discussion because ... setProperty,
also setPropertyValue and setPropertyPriority
dbaron: Whole idea of this being unordered set of things doesn't fly
anymore
dbaron: All implementations maintain it as ordered
dbaron: We need the ordering if we are going to do logical properties
zcorpan: Spec describes an order
dbaron: Yes. Not sure it's correct, but does describe an order
dbaron: Behavior you get in some cases is weird, because of finding an
existing case and making it not (??)
dbaron: We're really not following the model that it's logically append
dbaron: Because if there's an existing declaration, replacing parts of it.
dbaron: I would be fine with SetPropertyValue/SetPropertyPriority
dbaron: Would much prefer that to distinguishing emptystring vs non-value
...
zcorpan: Change setProperty to do what IE does
dbaron: Is everyone ok with changing to IE/WebKit behavior, behaves mostly
like appending?
zcorpan: I'm ok with that
TabAtkins: Yeah
RESOLVED: setProperty's handling of importance logically behaves same
as appending a declaration (like IE/WebKit)
RESOLVED: add a setPropertyValue and setPropertyPriority APIs
ChrisL: Rationale: David's been doing this for a long time and seems to
know what he's doing, so let's just all agree with him.
<TabAtkins> setPropertyValue appends a new declaration, stealing the
importance from the currently winning decl of that property
if it exists.
<TabAtkins> setPropertyPriority appends, stealing value. If no decl for
that property yet, either no-ops or throws.
glazou: glad to see addition of setPropertyPriority and setPropertyValue,
will really simplify some of my code
glazou: Not having to getPriority to set a value would be great. I like
this resolution a lot.
<dbaron> (Also, there was some discussion about what setPropertyValue
and setPropertyPriority would do when there's no existing
declaration: we talked about setPropertyValue behaving like
setProperty with "", and setPropertyPriority would either
need to no-op or throw.)
Received on Thursday, 19 September 2013 08:24:35 UTC