| 03:53 | <karlcow> | embed src to html document… showing the doc or not? |
| 03:53 | <karlcow> | https://bugzilla.mozilla.org/show_bug.cgi?id=730768#c3 |
| 03:53 | <karlcow> | Blink yes Gecko no |
| 03:53 | <karlcow> | I wonder what IE does |
| 10:59 | <frivoal> | Is there a generic name for the all html elements that are meant to hold "content" (p, section, article, h1-6, blockquote...), by opposition to elements used for UI and page construction (input, button, label, menu, br...)? |
| 11:02 | <boogyman> | frivoal: http://www.w3.org/TR/2011/WD-html5-20110525/content-models.html |
| 11:05 | <Ms2ger> | https://html.spec.whatwg.org/multipage/ |
| 11:29 | <frivoal> | boogyman: Thanks, that seems like the right place to look at. Unfortunately that classification doesn't seem to have a category for what I want, at least not without complicated unions/intersections/differences |
| 11:29 | <frivoal> | I'm looking for the set of elements on which is is generally not a good idea to set "user-select: none", to make that a SHOULD NOT in the user-select spec |
| 11:33 | <MikeSmith> | frivoal: I don't think the spec defines any term for what you want, but you should ask Hixie when he's around |
| 11:34 | <frivoal> | MikeSmith: Thanks, I'll mail him. |
| 11:37 | <MikeSmith> | frivoal: I think the "palpable content" thing that Hixie coined might be closest to what you need |
| 11:38 | <MikeSmith> | which as I understand it just means those elements that should usually have some text content descendants |
| 11:38 | <MikeSmith> | e.g. the p element |
| 11:38 | <MikeSmith> | https://html.spec.whatwg.org/multipage/dom.html#palpable-content |
| 11:38 | <frivoal> | Ooooh, sounds like it might. That was not in the w3c spec. |
| 11:39 | <MikeSmith> | yeah it is I'm pretty sure |
| 11:39 | <MikeSmith> | that link boogyman provided is to an old TR draft |
| 11:40 | boogyman | goes to update his references |
| 11:40 | <frivoal> | indeed. The world doesn't seem to suck after all. |
| 11:41 | <frivoal> | Great, no need to mail Hixie then. |
| 11:41 | <MikeSmith> | hmm, there's a bug in that definition; Hixie has the input and button elements and some other void elements in that "palpable content" category but clearly they should not be |
| 11:41 | MikeSmith | will file a bug for that |
| 11:41 | <frivoal> | duh |
| 11:42 | <MikeSmith> | sometimes even Atlas shrugs |
| 11:42 | <frivoal> | :) |
| 12:12 | <darobin> | MikeSmith: button has content |
| 12:12 | <MikeSmith> | oop |
| 12:14 | <darobin> | but that's not what palpable content is |
| 12:14 | <darobin> | elements that are meant to hold content ought to have at least one content item that's palpable |
| 12:15 | <darobin> | I'm not sure exactly what frivoal is looking for, maybe flow content is the closest? |
| 12:15 | <darobin> | but it's not an exact match |
| 12:17 | <frivoal> | Maybe what I want doesn't exist. in content vs structure vs ui, I want just content. But maybe elements cannot actually be split that way. |
| 12:17 | <Ms2ger> | I doubt it |
| 12:17 | <darobin> | frivoal: I'm trying to figure out exactly which elements ought not to have user-select on them |
| 12:17 | <darobin> | frivoal: I'm guessing anything that can be interactive and anything that contains something that can be interactive? |
| 12:18 | <darobin> | it would help to know exactly which warning/issue you want to flag |
| 12:18 | <frivoal> | darobin: user-select: none, specifically. user-select:all or user-select: element doesn't seem bad to me |
| 12:19 | <darobin> | frivoal: yeah, but I meant more generally what is the problem you wish to SHOULD NOT in the usage of user-select:none? |
| 12:19 | <darobin> | user-select is a pretty dangerous thing to boot |
| 12:21 | <Ms2ger> | "Authors SHOULD NOT use user-select." |
| 12:21 | <frivoal> | darobin: The problem is: 'user-select: none' is a UI convenience feature, not a copy protection mechanism. Warn authors that they're likely doing something wrong if they're applying it to <p>, <h1~6>, <em>, etc |
| 12:21 | <darobin> | I would spec it as "You MAY use user-select: none as you wish, but you should be advised that most legislations consider it acceptable for users to stab you in the face if you do it wrong. Also see 'Disabling user scale'" |
| 12:21 | <frivoal> | my issue being what's "etc" |
| 12:21 | <darobin> | right |
| 12:22 | <darobin> | "You should only use it in SVG and, if you really know what you're doing, in Web Components"? :) |
| 12:22 | <frivoal> | I've already put some language in the spec trying to tell people "you're doing it wrong", and to tell browsers that they're allowed to provide ways to bypass it. But I'd like to empower validators to complain as well. |
| 12:23 | <darobin> | (The intersection of people knowing what they're doing and still using Web Components may be too small to be worth mentioning, though.) |
| 12:23 | <darobin> | I see, but I'm trying to think of a case in which you would set user-select to none on an existing HTML element and it's not a mistake |
| 12:23 | <Ms2ger> | Doesn't "using WC" imply "not knowing what you're doing"? |
| 12:23 | <darobin> | you're a bit slow there Ms2ger, I made that joke two lines up :) |
| 12:24 | <darobin> | frivoal: the only uses I can think of would be on stuff like tabs, but I'm not sure that there's a way of distinguishing the acceptable markup constructs for those |
| 12:24 | <frivoal> | whether using WC or not, applying it to UI-like things which are surrounded by content sounds ok, as you're trying to make the content more easily selectable without grabbing the UI elements as well |
| 12:25 | <MikeSmith> | frivoal: which validator? the HTML checker? |
| 12:26 | <darobin> | frivoal: e.g. I can easily see a tabs thing where you set it on DT because that's what you're using for your tabs (which could be legit in some cases); but most of the time it's still wrong to do so on a DT |
| 12:26 | <frivoal> | MikeSmith: I'm a spec Editor. Leave me alone in my disconnected ivory tower and don't bother me with actual questions relating to real implementations of things. /s |
| 12:27 | <darobin> | lol |
| 12:27 | <frivoal> | darobin: if you're writing a mail client UI, you probably don't want all the buttons and labels like "To:" or "Subject: " to be selectable |
| 12:28 | <darobin> | frivoal: I agree; but I can't think of a way of abstracting that to something validatable |
| 12:28 | <frivoal> | darobin: The failure to do so is what brought me here, hoping to find wiser people. |
| 12:29 | darobin | points at /topic |
| 12:29 | <frivoal> | (this is where I might have gone wrogn) |
| 12:29 | <frivoal> | s/wrogn/wrong/ |
| 12:29 | <frivoal> | I'm looking for wisdom, not logic, so the topic is irrelevant. |
| 12:30 | <darobin> | frivoal: here's what I would do in a linter |
| 12:30 | <darobin> | I would look at the length of the text content under something that's user-select:none |
| 12:30 | <darobin> | and above a threshold, I'd warn |
| 12:30 | <darobin> | that ought to catch uses for content protection |
| 12:31 | <darobin> | I don't think you can do more |
| 12:31 | <darobin> | Conformance checkers may warn if the amount of text contained blah exceeds a certain size. |
| 12:32 | <frivoal> | you don't think "palpable content" - "form elements and similar (which is a bit broader than interactive element, as it for example includes <progress>)" would cut it? |
| 12:33 | <darobin> | palpable content means that you couldn't use it on a dl or ul that's used for a menu for instance |
| 12:34 | <darobin> | or for that matter on a div or span, which are likely to be the building blocks used in a UI — you're killing the use case there |
| 12:34 | <darobin> | I guess that setting it on a form element is likely wrong (the author probably wants disabled) |
| 12:36 | <frivoal> | for divs, spans, dl and ul, that's why I'm making this "SHOULD NOT" rather than "MUST NOT". |
| 12:36 | <frivoal> | for form elements like buttons, it's fine. For form elements that contain editable text, the spec takes care of that by making it compute to "element" (aka "contain"). |
| 12:36 | <darobin> | frivoal: yeah but... the primary use case applies to those element, it's weird to have them under SHOULD NOT |
| 12:37 | <frivoal> | yah |
| 12:37 | <frivoal> | yeah |
| 12:38 | <frivoal> | So we may have to live with heuristics, which is kind of hard to spec for. |
| 12:38 | <darobin> | frivoal: in general I am not convinced that specs should define linting behaviour |
| 12:39 | <darobin> | IMHO it would be better to have that specified separately, which in turn makes it more straightforward for different constituencies to have their own linting |
| 12:39 | <frivoal> | darobin: When something has clear cases of "this is bad, don't do it", I'm in favor of putting that in the spec, possibly in a way that give authority to validators to complain about. But if it's not a clear case... |
| 12:40 | <MikeSmith> | fwiw I have added warnings in the HTML checker that aren't requirements in any spec |
| 12:40 | <MikeSmith> | so I don't need for a spec to say it's OK |
| 12:40 | <darobin> | frivoal: if it's obviously bad, as in both nocive to users and reliably detectable, then sure |
| 12:41 | <darobin> | but the list of such things is short, and in such cases there's an argument to be made to have implementations reject it (assuming it's not a historical blunder of course) |
| 12:45 | <frivoal> | Darobin: I think I'm convinced that this case is not simple enough to spec. There are probably enough warnings already in the spec to give the right idea to people who care, and if they're not going to care, whatever I say won't make a difference |
| 12:46 | <MikeSmith> | If I were you I wouldn't give up until Hixie weighs in |
| 12:46 | <MikeSmith> | he's known to have a few ideas about this kind of stuff now and then |
| 12:51 | <frivoal> | MikeSmith: that spec is far for being frozen in REC, and I have mailed hixie, so we'll see. But I am not too hopeful at this point |
| 12:52 | <Ms2ger> | Hah, rec |
| 12:56 | <MikeSmith> | indeed our friend Rec is a real kidder |
| 12:56 | <MikeSmith> | he's the one in our cartoon who always does stuff like accidentally blowing up our moonshine still |
| 12:57 | <MikeSmith> | but afterwards we laugh about it together as we drink up our remaining moonshine |
| 12:59 | <MikeSmith> | hey I even found a picture of good ole Rec http://goo.gl/L5aHj0 |
| 13:02 | <MikeSmith> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28728 |
| 14:53 | <jochen__> | /act |
| 14:54 | <jochen__> | :-/ |