HTML F2F Day 2 -- 29 Mar 2017

CMN: No, haven't gone through all my mail

SF: What chat stuff do you use at Q42?

GB: 90% Slack, rest is emails. Try to use email less and less

<chaals> s/taewan/taehwan/

<sangwhan> Here, in a meeting though.

<chaals> Sangwhan, can you give us a useful time when you can discuss issue 538 - IDN email?

<sangwhan> Would you prefer a dial-in or a brain dump over IRC?

<chaals> [Unclear whether we can assume the editors who are not here think their issues are straightforward, or they have just done no triage :( ]

CMN: Yesterday we went through issues.

People here, please go through your lists and see if you're OK with the status

SF: (explains what we did yesterday to today's new attendees)

<sangwhan> Linkdrop: https://tools.ietf.org/html/rfc6531 https://tools.ietf.org/html/rfc3492 https://tools.ietf.org/html/rfc3490

<sangwhan> RFC6531 is the real problem here, there is a chicken and egg problem (Poor MTA interoperability)

SF: Do you have internal style guides on how to use HTML?

RJ: No, each team uses different tools to validate

[Discussion about validation tools]

<sangwhan> I can dial in in about... 20 mins if that works.

<chaals> Yeah, that would help I suspect.

[More discussion about semantic meaning for assistive technologies]

GB: We kind of assume every front end developer knows their way around HTML, and assume focus on JS. We find heading structure is not that solid.

When it comes to screen readers, what does the reader tell you? More often than not it doesn't make sense.

Using tools helps a lot

CMN: Talk bout Issue #561
... Issue #832, let's talk about it now.

https://github.com/w3c/html/issues/832

XQ: I'll go through the list to see what's broken

LW: Would it make sense to explain to Terence how to do it, to help him get involved?

I would explain to him what needs to happen

CMN: Has anyone checked the multiple attribute on email inputs?

It'd be handy to test

AD: It's in the RFC, comma separated works for SMTP

CMN: Be nice to know if browsers choke

<SteveF> multiple attribute support https://www.wufoo.com/html5/attributes/08-multiple.html

LW: What's this info about building and bikeshed update followed by copying the spec data files?

AD: I've never had to copy anything, it's bad info

CMN: I'd like to talk about read only on non-text input types

We had an issue for a couple of specific things, it's a generic issue really. WHATWG started looking at the question, read only only works on text input types. That means it works by default on any unsupported type

If you do read only on certain types of control, browsers seem to implement read only, then go back later to fix them

Seems easy to implement that the controls be read only is a feasible thing

Does it make sense to allow read only controls?

[Call setup for Sangwhan]

<sangwhan> I would imagine so. Locking a UI component in say, a configuration panel that gets disabled due to a dependency is a fairly common thing in native.

SW: Issue I'm assigned to is hard

Lets start with the LHS

That side has really bad real world interoperability with servers

Even if we allow users to do that, there's very little value added in adding this

Because email is a relay mechanism, if any MTA in the middle doesn't handle this mechanism, then you have problems

I'm sure we don't want to allow the LHS to use SMTP-UTF8

There are cases where there's magical punycode translation

That could be a problem with interoperability when people cut & paste

Punycode might solve some of it, but needs cross-browser collaboration to work

Support of IDN8 is possible for RHS.,

LHS I don't think we should do

We could file browser bugs and see if the browser vendors implement this

Use of the email field is not very high anyway, people just use text fields

<Zakim> chaals-temp, you wanted to point out that since people use text input to get around this, we already have the problem of mismatches where people do this.

CMN: I'm not sure what we should do about the LHS

I have an IDN email address in Russian

If you send UTF over the wire, you're not going to have a good time

There's been work to make some of the big systems work properly with UTF-8

That said, the argument that you log into a non-ASCII account name and go to a different browser, you'll see it doesn't work

There's a reasonable case to be made that the uptake path is reasonable (switch browser)

You see government in India pushing this, Russia as part way to pushing it

We should look for up to date info about what's implemented

SW: I went through commit logs on MTAs, it's rarely supported

CMN: The validate down to punycode, leave LHS as ASCII doesn't seem hard

Just need a punycode translator before we do validation

SW: Maybe find consensus on what the browser vendors think

If it's doable, it's not rocket science

CMN: It's literally putting a punycode translator before the validator

IDNs all have to translate into punycode, right?

SW: IDNs are a user level feature, the DNS resolution happens at the ASCII level

CMN: If we split the issue into 2

Yesterday, we said in a WD, we can put in 'do the RHS' and file browser bugs, mark it at risk. If it doesn't get implementations, it doesn't go to Rec

Seems reasonable to have the IDN on the RHS marked at risk

Hold off on the LHS, since it's much less widely deployed

ICANN are chasing up implementations of this, so follow their progress

SW: Guess we can live with that

CMN: Won't be in 5.2 time-frame

No way the LHS stuff will be implemented in that time, even difficult for 5.3

SW: When there's email, there's legacy interop problems

I doubt this'll get enough traction in the near future. e.g. Exchange server 1999 being used somewhere

I could come up with a simplistic way to do validation and see what people think

CMN: Do you want to take that issue?

SW: Sure, next month or so

CMN: Would be nice for this milestone in the WD

SW: Let me give it some thought

CMN: I could do a PR

All of your other issues, have you triaged?

SW: Half seem doable, will work on them

Couple of hard issues

Finding consensus for them will be hard

CMN: You should tell us which ones

#538 is icky

#375?

Vsync

Most people won't see this unless you're wearing VR headsets

What's the relationship between #785 and #375?

Seems like a dup

SW: If this work has been done upstream there's a possibility of getting it working

CMN: Suggest we link the issues, and make #785 the one

#314 you said?

SW: Yes, default style for a given element in use in the wild

Risky

CMN: Yes, it's risky, It'll need discussion

Let's push this to WD7 and push a real discussion

SW: Are we happy with the regression scope? This will break real content out in the wild

CMN: It's about nested quotes where you're shifting language in the nested quote. Should the quote marks match the language inside them or the language outside, Currently it matches outside

The suggestion is we change the rendering to match the inside quoted language

Is this going to cause issues, or improve things?

i18n group argue it'll make things better

CMN: It's unlikely to be a large number of pages affected by this, but also it's probably an improvement

GB: If you ask me, if the spec before doesn't follow the language rules, then the spec is at fault

It actually makes sense

CMN: It's inline layout for all these cases?

SW: Yes, changes the pseudo-elements that get inserted for quotes

CMN: I think this is a no brainer, but we should push it out to milestone 7 to give it time for discussion

SW: I'll chase down Florian for this
... #253 I won't do this week

#269 I won't do

CMN: I will have a look if I can do #253