<emilio> florian: which is what has happened in the TV world
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3299
<heycam> ScribeNick: heycam
futhark: Chrome is soon shipping
dark mode for the UI of the browser itself
... respecting the dark mode setting of the OS
... but we also want to render the pages dark
... so the MQs 5 hsa prefers-color-scheme
... letting the authors follow the setting the user has
... but in order to render the content dark for all pages from
day 1
... we're looking at a UA intervention that automatically
darkens the web pages
... but giving the author the possibility to opt out of
that
... and we have looked at a <meta> element that Apple has
already implemented
... what it does is that you can specify which color schemes
the page can respond to using MQs
... and apply a UA style sheet which renders form controls
dark, having a lighter foreground color, using a black canvas
backgrdop
... this is basically what safari does
... the proposal here is that we do this with a <meta>
element
emilio: also the CSS property?
futhark: the CSS property I
haven't mentioned yet
... there's the posisbility for the page saying that parts of
the page are styled itself, but also the possibility to do
automatic darkening of other parts of the page
... we get this request for various Google products
... where they want to handle some UI parts themselves in
dark
... but automatically darken some content
smfr: we have to distinguish
between auto darkening, which is clobbering what the author's
done
... and this thing, which allows the author to tell us they've
thought aobut dark mode
... for us this is jus chanign form controls, selection,
...
... an auto darkifying thing is maybe orthogonal to this
futhark: what we've been thinking
about is that the <meta> element at the same time it says
it wants the dark UA style, it would also opt out of the auto
darkening
... because it knows how to render dark pages
... when the author has a <meta> saying it knows how to
render this page in a dark color scheme, please opt out of auto
darkening
... one of the reasons we've been thinking about <meta>
is that we don't want any flash of white background
... so having it available early
dbaron: I agree with a bunch of
what Simon said
... there's a long standing problem we've had which is that
when we use native form controls and certain things like that,
if the user has a dark theme, those don't work with some
pages
... e.g. text input is a common one. if the text input has a
dark background with a light text color, and the author
overrides only one of bg/fg, it's broken
... as a result we've done work to prevent dark native themes
to get through to web content
... some recent Gtk changes broke this
... so I think there are a few separate problems here
... one is the fact that because of these dark theme options in
macOS, Windows 10, etc., more users have dark themes
... and in a lot of web contne tthat doesn't work, even if they
want it to work
... but we can't just go apply it to web content unless we know
it will work with that
futhark: that's why we want to rely on the meta element to have the page tell us it's ok
dbaron: I think a meta that says
"I the page author have thought about this and I know that my
page will work with a dark theme" is a good thing
... I think UAs could use it for different things
... one could use it to say "the user has a dark theme, so I
will let dark theme data theme, and use the user's preferred
form controls for this page"
... or the UA could say "for pages that haven't done this, do
auto darkening"
... and a meta that says "I suppor tdark theme" serves both of
those purposes but not completely
... if the user wants the entire thing to be dark, working with
dark form controls doesn't imply that their whole UI is
dark
... so they still might want the auto darkening in that
case
... another thing in here I don't like. it also allows authors
to say that their page doesn't work with light pages
... and I'd rather not create this problem
futhark: the only keyword?
dbaron: you can say supported
schemes "dark", and skip light
... in the spirit of trying to do more of what the user wants,
where right now users want to see things in dark mode, I'm
hesitant to give authors an option to say this page doesn't
work in light mode
... for users who want that
futhark: there's also the "only"
keyword that Safari implements
... don't you have to say "dark only"?
smfr: [nods]
futhark: if you have a light theme and say "dark only" in the meta tag, you get the authored dark page
dholbert: and widgets are dark?
smfr: primarily widgets
fremy: I am very curious about
how you're going to enforce dark themes on pages that aren't
prepared
... I'm skeptical people will like that
... you'll end up with images that look wrong etc.
... for a11y purposes it's a fair tradeoff
... but I am very unsure that people going to bing.com that
doesn't support dark theme now the links aren't visible
futhark: auto darkening is not something we'd like to spec
<fantasai> +1 to fremy
fremy: otoh, replying to david, I
don't see why you'd want dark only
... in VS Code, a web app, it has dark menus
... it makes sense for them to say "dark only"
... they want to control all their app UI
... if you're talking about wikipedia, they should probably not
say "dark only", but I don't think they will do that
... maybe for a powerpoint thing, if the author has thought
about it, why prevent it?
dbaron: one of my worries about
this stuff is that not all browsers will be able to do all of
these things
... if we want web pages to be able to say "dark only", the
browsers need a native set of light and dark controls
... which on some platforms is not realistic
fremy: you can always have a normal styled fallback for form controls
florian: that's the difference between I prefer dark and I support dark only
<fantasai> slides from the earlier high-contrast discussion: https://lists.w3.org/Archives/Public/www-archive/2019Feb/att-0000/CSSWG_F2F_High_Contrast.pdf
florian: if you don't have dark
controls, and your OS doesn't have them -- that's different
from saying "if you show light controls I will be broken"
... we shouldn't have that
... why create that category?
... there are some that would look better with dark
controls
fremy: VS Code only has dark controls
<fantasai> high constrast explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md
fremy: why do they custom style
everything? because they can't get dark controls
... I think what you're saying exists today
... but the web page custom styles every single thing
florian: if the OS doesn't support dark controls?
fremy: you fall back, just like when you put borders on form controls
florian: so VS Code will still need to hand code their dark controls, since they can't handle that some OSes will fall back
fremy: today the light controls
have this fallback today
... if you have a button border-radius:3px, you get the
fallback rendering
... and you can do this same fallback for the dark one
<fantasai> high contrast explainer archived:
<fantasai> https://lists.w3.org/Archives/Public/www-archive/2019Feb/0001.html
dbaron: I think there is a
tradeoff here. some sites that want to own things so much they
will replace the native controls
... there's a tradeoff betwene that and having sites where the
controls are more recognizable as such to users
... and the users recognize the thing over there is an input
field
... that's a tradeoff
... there's an advantage to contrls that look native
... esp for less experienced users
... if we offer more ability to change what the controls look
like, we will pull some designers away from replacing
everything
... but we will also push some users into things that are less
recognizable for them
... there's no one answer is more correct 100%
florian: afaict, the property
here, whether it has a bunch of properties or auto vs
i-support-dark, does the same thing at the meta tag? just at a
subtree granularity
... whether or not you suppor tdark theme depends on the style
sheet, so it belongs in the style sheet rather than meta
tag
... I know I will not get full agreement on that
gregwhitworth: for end user experience reasons
florian: but it could become wrong when you update the style sheet and forget to update the meta
gregwhitworth: bad author
florian: if you have a page that claims to support dark mode, the author sheet does support dark mode, but user sheet doesn't -- how to tell the page?
futhark: the property wins
AmeliaBR: I'm a bit uncomfortable
doing style theming in the meta tag because you might have all
sorts of flexible themings based on user prefs based on your
own thing
... but as long as the style property overrides the meta tag,
that's ok
... but then I'm not sure why the meta tag is necessary
... if the style sheet sdon't load, I'm assuming the browser
can apply whichever one
futhark: if you parse the meta tag, you can apply the black canvas pretty early
fremy: it's about flashing
AmeliaBR: is there any reason to do the flashing? if the style sheets haven't loaded can't you have a default bg that is according to the default theme?
smfr: every wikipedia page will flash
AmeliaBR: ok that's the point of the meta tag, for the default backdrop before style sheets load
fantasai: use bgcolor on body?
:)
... I totally agree this is not something that belongs in the
HTML layer if possible
... if you want to put it there, we have bgcolor
... the best thing there is you can solve that for any
background color
AmeliaBR: not necessarily because what if the style sheet has a MQ switch based on user preference
fantasai: then it will override, but that's better
AmeliaBR: you can indicate which themes you support
fremy: bgcolor can only supply black, not "which theme the author supports"
fantasai: you're only doing this for white or black -- is this a big problem?
TabAtkins: if I'm looking at dark screens in bed, I don't want a big flash of white
AmeliaBR: why would wikipedia put a meta tag saying "dark only"?
florian: they won't hae the tag, so you know it's a light site, but you can still show dark until it shows up
[wikipedia just as an example here]
AmeliaBR: my other point,
repeating some of fremy, if there's any discussion about auto
applying styles without author opt in, that should be discussed
in the context of accessibile color schemes, high contrast
mode, think of it that way
... when you're overriding author styles it's an a11y
feature
... but that's separate from trying to match user
preferences
... for matching user prefs, I like the idea of making it
easier for authors to say this site supports a dark theme, draw
default styles for select boxes, if you have one, or saying my
styles work well whether you use light or dark whichever the
user prefers
... there are sites that are dark that require custom styling
for form controls now, so I like the easy way to opt in to
native dark mode styles
<fantasai> +1
AmeliaBR: we kind of have
multiple themes now in browsers
... the "legacy" widget themes, if you much around with
styles
... then we have the modern native look buttons in light or
dark theme
... I don't know how is the way the prop is currently specced
going to interact with that?
... when you revert to the legacy styles
futhark: I don't have an answer for that
AmeliaBR: if you use this prop are you saying "use the native UI look no matter what other styles I put on the element?"
smfr: still has these fallbcak interactions
AmeliaBR: so if I wanted styles
that say use native dark mode, but if you don't support these
new props, and if I want a custom styled dark inputs, you'll
need @supports or something?
... will @supports just look at syntax, don't say you support
dark mode unless you have one to use
... but that would break an author request of dark or
light
... so the keywords need to be recognized even if they don't
have matching themes
... can sites detect "do you have a native dark theme"?
emilio: that's a fair
request
... an author to see if the browser suppotrs a native dark
theme or not
... it feels to me that the auto darkening has a lot of
potential to backfire
bdc: I think there are 2 different issues
<fantasai> +1 to emilio
bdc: one is that it makes a lot
of sense for a page to fit into its environment
... the other use case, which I disagree with, is fremy's
example of "I'd prefer a dark theme for my app so I will just
use theme by requesting dark controls"
... it's a design shortcut
... it's a differnet purpose IMO
... VS Code is not designing that because they don't have
access to a dark mode
... they just design it that way
... to me it's a different use case
... to want to re-use a set of controls that are nicer to the
designer's eye is different from fitting to the environment
<florian> +1
fremy: the #1 request we got for
controls in Edge is sites wanted dark scrollbars
... we don't want to customize the scrollbar, we just want a
dark one
... when they do customize it, we get perf issues, etc.
<fantasai> I would like to point out that Adobe Creative Suite uses dark mode for its UI, but the expectation is that content being edited is black-on-white, so it's not that you always want to match content to the OS "theme".
<tantek> +1 same we get requests for dark scrollbars primarily
<fantasai> Sometimes. not always
fremy: that's the point of this
prop, this area of the page is dark, it's a choice we made, but
we want to play nice with native controls
... for better UX for users
... also, let's say you have a blog engine, you want to support
dark theme
... so you say the page supports light and dark
... an embedded component from another origin, it only
supportslight
... you need to have a way to say this part of my webpage does
not support dark theme, even though my site overall does
... this is the point of the property
... incorporating components from different sites, you might
not want to give up your overall site dark theme
... the "dark only" value might not be useful ...
... I have seen sites that just want a dark scrollbar
... and you need "light only" anyway
AmeliaBR: anothe rexample, you're
concerned it's not respecting user prefs
... for somethings I like a dark theme, but if I'm reading a
lot, I can't read a lot of white text on black bg
... so I'm going to have different prefs for different
sites
... maybe browsers will one day allow me to set prefs on a per
site basis
... but lots of sites have a way for the user to opt in to a
theme
... so maybe when they're doing "light only" or "dark only",
they're reflecting the user's preference in the site
bdc: the way I would summarize is
that letting the browser know that you are dark theme
compatible is nice, a good citizen in this environment
... doing the opposite is being hostile to the env
... whatever you choose, I'm going to have dark, because I like
it
fremy: but you could have a theme inside the app
AmeliaBR: we can encourage
authors to make their sites theme flexible
... just like responsive sites
... but I don't think a dark only is any more hostile than
saying background-color:black, etc.
... it's just one way for the author to opt in to a color
scheme without setting everything themselves
... and making it a bit more native and familiar
bdc: I see that, but it really
depends on how many things in the UI that change
... e.g. at some point I think Edge had a title bar that
matched the site header color
... here you're forcing UI changes because use as an author
prefer black
... it might be pushy
Rossen: we used to have a mode
that when you pin a site to the taskbar or start menu and you
want to use it exclusivle in an app mode
... we would do small things to match the page
... that was the behavior we did
bdc: this kind of thing can have
an impact on the UI as a whole
... who knows what the OS will do in the future
... so it could affect more things
AmeliaBR: good point but it
sounds like it's outside the scope of CSS
... anything the browser/OS is doing to extract styles from the
page and applying outside the page ...
bdc: these properties and meta tags would do that no?
florian: just within the page
AmeliaBR: the only thing outside what we can already style with CSS is styling the dark/light bg of the canvas
bdc: the chrome of the browser could/should change based on that
gregwhitworth: the way I would
see this working in Edge, user turns on dark mode, Edge would
flip into dark mode, devtools would too
... if you have the meta tag, it would flip to dark controls
too, if not, it wouldn't
... is there an issue with that?
bdc: not with that
... but in the future making the assumption that if the site
opts in that other UI is now dark, then I do
dholbert: alerts could be dark
gregwhitworth: they're not controlled by you now anyway
AmeliaBR: that's an issue on the browser team to decide whether to respond author or OS choices ...
Rossen: the one thing to keep in
mind is that at least in Windows, probably on macOS, we have
three levels of where color schemes can apply
... there's the shell, which is only controlled by the
user
... usually it doesn't propagate anywhere beside the
shell
... then there are apps. apps are going to depending on the UI
framework they use, they may be either forced or opt in to a
particular color theme
... regardless of it it's dark or whatever
... then there's the content of these apps
... even besides browsers. many other apps that have content
that could benefit from theming
... and there, it's the choice of the app on whether to
propagate that information to the content
... a quick survey of 1st party apps that ship with Windows or
macOS, even there is some inconsistency
... e.g. in Windows the shell is always dark, doesn't mean 1st
party apps will always be dark
... at the same time, in Edge, there's a user choice to change
the UI to be dark mode only
... changing the UI of the browser alone doesn't fit with
anything else if the shell is light
... for these cases, to say that because I'm switching my app
to be dark, I want everyhing else inside to be dark
... Mail doesn't usually force content to be dark by
default
... looking at macOS Mail, it seems this is only done for text
only messages
... propagating this down to the site and alowing the site to
say "yes I'm fine if you are going to change your UI,
regardless where the change came from, I'm going to match it a
bit better"
... so I think the overall approach of this proposal doesn't
seem crazy, it's just that how do we get to the point where the
actual handshake between content and the app layer becomes as
transparent/easy as possible
... most platforms today have these 3 tiers of color scheme
propagation that, whether or not in this group agree, is
irrelevant
futhark: one of the things I
wanted to figure out is if a meta tag is the right way to do
this
... the standardization of a meta tag typically doens't happen
in CSS
Rossen: what are you optimizing
for here? style sheet download, so that before you navigate you
want the right theme applied without flashing?
... if you're going from page to page on wikipedia, and let's
say wikipedia had a dark mode, you don't each navigation flash
to white
... if we're ok with flashing, then meta tag or property or
alternative style sheet would work
smfr: we're not ok with
flashing
... asked one of our engineers about the meta tag
proposal
... there are clients other than browsers, like mail client,
it's useful for them to be able to parse the first part of the
message without a css parser
... I think that's the primary reason
florian: I'm personally not
enthusastic about the meta tag, but I understand why you need
it
... and as long as you have the property, that's fine
bdc: the only change you're contemplating is form controls, root viewport color
futhark: foreground color, background color
<tantek> I'm curious if a <style> element would solve the flash or not
florian: would this change the bg color of the selection?
smfr: yes
florian: that's meant to be affected by a normal property on a selector
smfr: currently the selection
color uses a system provided color
... but this will be overridden
... there's also spelling dots
... and the scrollbar color, even though we have a property for
that now
... links too
jensimmons: does it also include the colors in the UA sheet?
hober: in practice we didn't have to, since it used named colors
smfr: in KHTML there was a system
color called "text"
... that value persisted to the present day
... now we're using that in the UA sheet
... that becomes white when you use dark mode
emilio: we should talk about,
because all UAs probably use system colors for this
... doesn't make sense to deprecate things that everyone is
using them...
dbaron: on system colors, I had a
bunch of proposals
... the current set is very Windows specific
... you generally think there is a fg and bg pair
... ButtonText / ButtonFace, HighlightText / Highlight
... in that set, from the Windows API, seeing how the Windows
UI used those, there were some non obvious pairs
... there was a set of 4 colors, call them ABCD
... it was confusing
... in 2001..2003, I had a proposal for fixing this by adding
another name for the other combinations
... rather than assuming this control always uses the fg color
from this control and the bg color from that control
... and Gecko implements a bunch of these behinds
prefixes
... additional system colors so we can do sane things on
non-Windows
... Dialog and Field
... I would support working un-deprecating system colors given
how much they're used, I had some proposals to fix them
... I think it's possible that it might make sense to have 2
different flags rather than 1
... it might be that the aspect of what to do with native
controls is different from what to do with default colors
... so you may wish to say that my page supports either light
or dark native controls, but I still want to leave the default
colors light by default
... not fully thought through
florian: I think that makes
sense. think of an existing dark today site, but was written
dark with the assumption the UA sheet is light
... and might rely on some thing sfrom there
... even if they want to opt into dark controls
emilio: but if you have no meta tag
florian: you add the meta tag to use the dark controls
emilio: hopefully you then check the page!
<fantasai> bgcolor=dark
<fantasai> :p
emilio: presumably if you request dark theme, look at your page, notice that it has light text that looks broken ...
florian: so don't ask for it and hack controls the old way?
<dbaron> https://dbaron.org/css/test/sec1802 has some examples of how the system colors work -- part of the mess is that there are both single-border and double-border styles for raised buttons, which is why there are so many colors for the edges of buttons
emilio: on one hand, I agree more configurability is nice. otoh, exploding the amount of combinations of themes and bits that you can tweak is also going to be a mess
florian: the #1 statement before
was dark form controls
... not a dark UA style sheet
... why are we coupling the two?
AmeliaBR: is the disclosure on details a form control or just a style sheet thing? so many things
florian: fremy earlier stated if
you try auto darkening you will get problem
... to me a dark UA sheet is a primitive form of that
fremy: but if it's opt in they
can fix it
... if they don't want to fix it that's up to them
Rossen: not having the foreground
color matching form controls would be strange
... let alone backgrounds
AmeliaBR: I suspect in most cases
the author is going ot override most of the things tha twould
be applied on non form controls, like on sites now
... but it seems nice to have the option to have a quick one
liner
... just write this web site in a light or dark whatever the
user wants
... or write this section in a generic dark style because it's
a chunk of text and we won't fuss on it too much
florian: if the meta tag switches
the UA sheet, does the property too? how do you switch the UA
from light to dark on a subtree level?
... if oyu have a meta dark, and this subtree light only, how
do you apply things from the UA sheet in that subtree?
Rossen: that's what we do for high contrast
florian: you have selectors that depend on the value of a prop?
fremy: the colors chnage
florian: change the UA sheet?
fremy: we don't have a UA sheet
for dark theme
... we switch a couple of colors
AmeliaBR: but this would allow to
opt in not just form controls, but also dark and the page will
be light text on dark background, which is essentially the dark
UA sheet
... right now we just have appearance
... whether browser styles apply to that element
... but it's only for isolated replaced elements, not paras
florian: if the only differnece
between light and dark UA sheets, and all differences are
system colors, that's doable
... if there is any difference, then you can't do that in a
subtree
<dbaron> The other fun question is whether the system color keywords are computed values.
astearns: I'm not hearing any
objections
... some research into what the meta tag would actually
do
... we need more details written down
tantek: other question this
raises is that there is a hole in the CSS rendering model about
initial / transitional paints
... and we're not addressing it
... and the jump to a specific solution like meta tag is a way
of ducking that problem
... I believe this group owns this problem
... not saying we're addressing it today, but we should admit
it's a problem
smfr: there are consumers of
HTML/CSS like mail clients without the same navigational
behavior as browsers
... when browsers paint during page load is in some cases a
differentiator between browsers
... we try to paint not too late or early
... not sure specifying that is productively
astearns: not specifying first
paint, but specifying some control over what happens in that
first paint to avoid flashes
... seems like a good thing to work on
fremy: first paint can happen before CSS
tantek: I sense a hole
... I won't diagree with smfr that browsers are motivated at
doing a good job at, just that it's a hole that authors have
asked for control of it, but we haven't provided for
... we can do a better job too, but those two are not in
conflict
astearns: can you raise an issue
on that?
... for the meta tag, seems like we should do some more work
and come back with a more concrete proposal
<fremy> scribenick: fremy
<astearns> github: https://github.com/w3c/csswg-drafts/issues/2390
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2390
emilio: Blink cannot seem to be able to unship
<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1296042
emilio: We considered the
alternatives
... but the usage in Blink is very high so even if they also
implemented the alternatives
... they would not unship
... I'm tired of getting new compat issues about this
... so, can we maybe as a group add this to a spec?
... maybe even mark it as deprecated
... it's sad but realistic
florian: I am annoyed that this
means we will have to care about this forever
... but I guess if this is required, I guess we will have to
live with it
... because both the name is bad, but also it's not on the
right property
... but well...
... ...
... is anybody sad enough that they are willing to object?
<giggles>
emilio: we could put it in a webcompat spec?
florian: no, if we do it, let's
do it properly
... as in, the text spec
astearns: so, all seem resigned
to accept this at this point, is that right?
... proposed resolution is thus to add it (back) to the
spec
fantasai: we have to decide if we
put it in the same table as the other values
... or in a prose section further down below
astearns: I like the latter
... level 3 or level 4?
fantasai: level 3 because it is not CR yet
dholbert: are we confident we can get this specced properly soon though?
fantasai: yes, we already have this exact behavior, just on another property
AmeliaBR: so we will have two values doing the same thing?
fantasai: yes
AmeliaBR: how will they interact
emilio: either or both would trigger this behavior
AmeliaBR: ok, seems reasonable
emilio: either must work on their own for compat
astearns: so, any object to add this to text level 3? with the explanation that people should use the other property?
RESOLUTION: We are resigned to add word-break:break-word to text level 3, with a note
Rossen: quick question about next
f2f meeting
... hosted in Toronto by Mozilla
... are the dates frozen?
florian: I hope so
Rossen: then we need to clarify the wiki
dbaron: I'm doing it
astearns: we might want to think
about our first meeting next year
... because tpac is really early
astearns: (this doesn't need to be minuted)
<dbaron> https://en.wikipedia.org/wiki/A_Coru%C3%B1a#Climate
<fantasai> Current proposal is at Igalia in January 2020
<fantasai> not conflicting with Mozilla All-hands, but either close to it (one trip for travelers) or far away from it
<fantasai> hober: It's been an embarassingly long time since we've hosted a CSS meeting, so throwing out there that we'd be happy to host next Spring
<rego> Mozilla all hands is: 2020 January 27-February 1 - Berlin, Germany
<rego> yep, rain is almost for granted, but in the coast is not going to be cold compared to the usual winter in north hemisphere
<rego> so I guess the week before would work?
<rego> pictures of Igalia office in the event we arrange every year: https://www.flickr.com/photos/webhackfest/
<astearns> trackbot, end meeting
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/outside we can/outside what we can already/ Succeeded: s/canvas/root viewport color/ Succeeded: s/(so far no noise is heard)/<giggles>/ Succeeded: s/add/We are resigned to add/ Succeeded: s/think/hope/ Default Present: krit Present: krit WARNING: Fewer than 3 people found for Present list! Found ScribeNick: heycam Found ScribeNick: fremy Inferring Scribes: heycam, fremy Scribes: heycam, fremy ScribeNicks: heycam, fremy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]