| 00:09 | <tantek> | TabAtkins: "There's an additional non-obvious command you have to run to actually get [something done]" is the general design philosophy of the Git CLI. |
| 07:47 | <jgraham> | TabAtkins: That's a flaw, sure, but it's kind of a dumb surface-level design flaw |
| 07:47 | <jgraham> | In theory git clone could be fixed to do the right thing |
| 16:24 | <kirillbykov2> | Hello! I'm new at HTML5/CSS3 and I have a question about CSS. Could someone explain me why the text color property's name is "color", but not "text-color"? It confuse me very much :( |
| 18:59 | <nox> | https://html.spec.whatwg.org/multipage/browsers.html#the-location-interface:reload-triggered-navigation Shouldn't that reference be the definition, instead of the one in the navigation algorithm? |
| 19:39 | <KiChjang> | i need some help understanding the content/IDL attributes of max, min and step on input elements |
| 19:39 | <KiChjang> | currently on FF and CR, they both treat them as simply strings |
| 19:40 | <KiChjang> | but then on the spec here |
| 19:40 | <KiChjang> | https://html.spec.whatwg.org/multipage/forms.html#attr-input-step |
| 19:40 | <KiChjang> | it contains the following paragraph |
| 19:40 | <KiChjang> | The step attribute, if specified, must either have a value that is a valid floating-point number that parses to a number that is greater than zero, or must have a value that is an ASCII case-insensitive match for the string "any". |
| 19:42 | <KiChjang> | does this indicate that user agents are supposed to parse them as floating-point numbers? |
| 19:43 | <KiChjang> | further complicating the matter, each input type also contains restrictions on what values that the max, min and step attributes can take |
| 19:43 | <KiChjang> | https://html.spec.whatwg.org/multipage/forms.html#date-state-%28type=date%29 |
| 19:43 | <KiChjang> | "The step attribute is expressed in days. The step scale factor is 86,400,000 (which converts the days to milliseconds, as used in the other algorithms). The default step is 1 day." |
| 19:45 | <KiChjang> | and for max and min |
| 19:45 | <KiChjang> | "The min attribute, if specified, must have a value that is a valid date string. The max attribute, if specified, must have a value that is a valid date string. |
| 19:45 | <KiChjang> | " |
| 19:45 | <KiChjang> | "If the element has a min attribute, and the result of applying the algorithm to convert a string to a number to the value of the min attribute is a number, then that number is the element's minimum; otherwise, if the type attribute's current state defines a default minimum, then that is the minimum; otherwise, the element has no minimum." |
| 19:45 | <KiChjang> | https://html.spec.whatwg.org/multipage/forms.html#attr-input-min |
| 19:49 | <KiChjang> | so are the behaviours observed on FF and CR wrong? |
| 20:51 | <Domenic> | KiChjang: that is an authoring conformance requirement |
| 20:53 | <KiChjang> | Domenic, what does that mean? |
| 20:53 | <Domenic> | KiChjang: that internal "minimum" of an element is obtained by the "If the element has a min attribute, and the result...". That internal minimum value is used in other contexts. |
| 20:53 | <Domenic> | KiChjang: everything else you quoted is an authoring conformance requirement, for validators, not web browsers |
| 20:53 | <Domenic> | KiChjang: the HTML spec gives instructions on how authors write valid HTML, in addition to giving instructions on how browsers must use any HTML |
| 20:54 | <Domenic> | s/for validators/for validators and authors/ |
| 20:54 | <KiChjang> | Domenic, ah, so there's this notion of an internal attribute as well |
| 20:54 | <KiChjang> | likewise, step should also have an internal representation? |
| 20:55 | <Domenic> | KiChjang: yes, it's https://html.spec.whatwg.org/multipage/forms.html#concept-input-step |
| 20:55 | <Domenic> | It looks like the "internal slots" for the element are "allowed value step" and "step base" |
| 20:56 | <Domenic> | those are derived by looking at the content attributes step, multiple, min, and value. |
| 20:56 | <Domenic> | per the algorithms in that section |
| 20:56 | <KiChjang> | i see, that clears up a lot of my confusion, thanks |
| 20:57 | <Domenic> | This is an ongoing problem with everyone getting confused by authoring requirements vs. processing model requirements :( |
| 21:03 | <KiChjang> | Domenic, well, one of the reasons is because i wasn't aware that there are internal representations for these values |
| 21:04 | <KiChjang> | on other places, the element would have something like "An element has an associated something value" |
| 21:04 | <Domenic> | That's true |
| 21:04 | <Domenic> | I guess the line is a bit blurry between "an element has an allowed value step" and "an element has an algorithm for getting an allowed value step" |
| 21:05 | <Domenic> | You could implement it either way |
| 21:05 | <Domenic> | Probably the latter makes more sense actually |
| 21:07 | <KiChjang> | Domenic, when i first read that, i interpreted as the latter one |
| 21:07 | <Domenic> | Yeah, I think that's how I would implement it |
| 21:08 | <KiChjang> | Domenic, also, does this mean that the behaviour in FF and CR are according to spec? |
| 21:08 | <Domenic> | KiChjang: I think it is, although I haven't tested in detail. |
| 21:08 | <KiChjang> | i.e. all min, max and step values do not need any input validation |
| 21:08 | <KiChjang> | and are stored as strings |
| 21:09 | <Domenic> | If you mean content vs. IDL attributes, yes, I believe the IDL attributes are defined to reflect the content attributes. |
| 21:10 | <KiChjang> | but why does the spec also mention that (e.g. for step) it "must have a value that is a valid floating-point number that is greater than zero, or must have a value that is an ASCII case-insensitive match for the string 'any'"? |
| 21:11 | <KiChjang> | it also doesn't list any consequences when the attribute violates this rule |
| 21:11 | <KiChjang> | so is that just there for show? |
| 21:11 | <KiChjang> | i.e. the strings for step doesn't and isn't validated at all? |
| 21:13 | <Domenic> | Those are requirements on authors |
| 21:13 | <Domenic> | The spec has multiple audiences |
| 21:13 | <Domenic> | Validators will complain if you write `<input step="asdf">` |
| 21:13 | <Domenic> | that is the part of the spec that tells them to do so |
| 21:14 | <Domenic> | the consequences are that your document will not be conformant |
| 21:14 | <Domenic> | https://html.spec.whatwg.org/multipage/introduction.html#restrictions-on-content-models-and-on-attribute-values |
| 21:16 | <KiChjang> | Domenic, ah, it took a while for me to get it, it's like a note for spec authors |
| 21:16 | <KiChjang> | should that not be in a notes section then? |
| 21:16 | <Domenic> | no, it's a normative requirement to those wanting to write valid HTML documents |
| 21:17 | <Domenic> | developers.whatwg.org (back in the day when it was updated) was basically a version of the spec with all the "for-implementers" stuff removed... I feel like we need a "implementers.whatwg.org" with all the for-developers stuff removed. |
| 21:17 | <Domenic> | (developers = authors, BTW) |
| 21:18 | <KiChjang> | Domenic, i see, so basically there are groups of people who are just wondering what the constraints are when using HTML, and there are those who are implementing HTML stuff on the browser itself (that's me) |
| 21:18 | <Domenic> | yeah, the spec has normative requirements on both |
| 21:19 | <Domenic> | but basically anything that's a restriction on a content model (what an element can contain) or an attribute value is for authors |
| 21:19 | <Domenic> | more at https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors ... restrictions on not using certain tags (presentational markup) or not writing invalid HTML (like <table><hr>...) |
| 21:25 | <KiChjang> | Domenic, maybe the wording could be a little bit more obvious as to which audience a particular snippet of the spec is intended for |
| 21:25 | <KiChjang> | i'm sure there had been discussion about this before though |
| 21:44 | <Domenic> | Yeah, it's just such a massive, widespread issue. Nobody's had the time or fortitude to tackle it. |